Tighten Up Your Strategy: Evaluating the Leakiness of a Cloud App

We at Netskope Threat Labs have published a series of blogs detailing the misconfigurations in cloud apps causing data exposure. Misconfiguration and sensitive data exposure have been listed as predominant top 10 OWASP security risks for years, and are now also the predominant cause of cloud data breaches.

Our earlier posts detailed the exposure risk of popular apps, such as Google Calendar, Google Groups, other Google services, Zendesk, Office 365, Google Photos, Google Hangouts, and Discord. This blog post will demystify the types of exposure and the factors causing exposure. We will provide a checklist of specific features to look for when deciding whether to use an app to store, share, or otherwise process sensitive data. This approach can help organizations to evaluate a cloud app first and then deploy the app with the best practices and tight security controls, rooted in the key principle: “Evaluate first, Deploy later.” And for apps that are already used for sensitive data, this blog provides a checklist of things to lock down within those apps.

Extent of data exposure

First, we will look at the extent to which an app enables a user to share data, whether it’s public or internal within an organization.

Public data exposure

Public data exposure refers to data exposed to the entire internet. One classical example is sharing data using cloud services from Google. In this screenshot, the user generates a shareable link that is publicly accessible.

Google also offers a “Publish to web” option to index the content in major search engines. This not only means that the data is publicly accessible, but it is also easily discoverable by outsiders and adversaries. Public data exposure is a problem in all of the apps we have covered, such as Google Calendar, Google Groups, Google link sharing, Zendesk, Office 365, Google Photos, Google Hangouts, and Discord.

Internal data exposure

Internal data exposure refers to the data shared within one’s organization. This exposure is related to the accidental sharing of confidential information throughout the entire organization when it is supposed to be confined to a specific person or function. Generally, the documents are shared with a link that allows anyone in the organization with the link to view the file. In Figure 2, salary information was accidentally shared with everyone in the organization via Google Drive.

These documents can be discovered using the search function in Google Drive by people other than the intended recipients. This opens the data up to insider threats or discovery and theft by a malicious actor who gains access to the app from anyone’s account. This has been exclusively covered in our leaky app series on Google link sharing. 

Risk factors

The next important aspect is the risk factors that contribute to cloud app data exposures and misconfiguration. These are broadly classified into three categories:

• Design factor
• Default factor
• Human factor

Design factor

Design factor refers to exposure risk inherent in the design of an app. One classic example is our post on Leaky images which detailed accidental exposure in Google Hangouts. In Google Hangouts, alongside the chat conversations, users can share images. These shared images are assigned a public link by the application’s design.

This link is universally accessible even outside of the application without any authentication. To take it a step further, a malicious insider can share snapshots of private keys, passwords, and tokens in a chat conversation. Because these are public links, they can be downloaded by anyone at any time. 

Default factor

Default factor refers to exposures that are caused by the default settings of an app. One example is the case of basic group permissions for a Google account detailed in Leaky Groups. The default “Group visibility” and “Join the Group” permissions allow anyone on the web to see that the group exists and ask to join. As the group is visible to anyone on the web, the threat actor can leverage this in multiple ways, such as DDoSing the group with multiple requests and requesting group access by impersonating members of the group.

Human factor

Human factor refers to the ways a user of an app may accidentally expose data. In one example we detailed, a Google Group was created for sensitive finance discussions within the finance team, but the group was open for anyone in the organization to join and view the past discussions. Due to the human error in the group’s creation, anyone in the organization can join the group and view data that should have been kept confidential within the finance group.

Evaluating your app exposure risk

How do you approach evaluating the risk exposure of a cloud app? We have compiled a list of questions to help you evaluate the three risk factors. Answering “no” to any of these questions means the app might not be suitable for sensitive data.

Design Factor

1. Are users required to authenticate to view content on the app?
2. Can an administrator restrict a user’s ability to share data with others?

Look for apps that require authentication and offer granular administrator control over data exposure. 

Default Factor

3. Do the default sharing settings make data private?
4. Can an administrator change the default sharing settings for users? 

Most users will just use the default settings, so it is important that they protect sensitive data.

Human Factor

5. Are there administrative controls that can prevent users from exposing data?
6. Does the app have guardrails ( such as warnings or alerts) in place to mitigate the risk of accidental exposure?

Locking down administrative controls, providing guardrails, or otherwise coaching users can go a long way toward helping prevent data exposure. 

Mitigating exposure risk

Once you have decided to use a cloud app, we recommend the following steps to mitigate the exposure risk:

• Customize admin settings to restrict user sharing to only others within the organization or specific individuals.
• Prevent users from uploading sensitive content to apps that have a high exposure risk.
• Restrict sensitive content to only sanctioned instances of cloud apps by preventing users from uploading sensitive content to any other app instances.

Netskope Cloud Confidence Index™

Netskope’s Cloud Confidence Index (CCI) measures the enterprise-readiness of a cloud app and is adapted from the Cloud Security Alliance (CSA) Cloud Controls Matrix (CCM). Enterprise administrators use the CCI score to identify apps that are enterprise-ready (those with a score of at least 75). The CCI also provides details of each of the factors contributing to the score, enabling administrators to weigh each factor according to their needs.

Conclusion

While this post provides a checklist to help you determine whether an app is suitable for sensitive data, it is important to remember that modern cloud apps are complex. Organizations often purchase a whole suite of apps from a vendor, and each app may have its own set of controls and exposure risk factors, so it is important to evaluate each app individually.